Strides
Strides are configuration around how to group players by their available ranks for matches. These are necessary for performance because each stride that is generated is required in order to process different groups for matchmaking simultaneously.
The stride configuration is used to generate profiles with pool definitions based on the number of players in the player pool at that time.
Pools can only reference the search_fields of tickets.
This means that for any ticket with multiple players, the rating of the ticket is used to distribute the work instead of every individual player's ranks.
This makes it very important to set the MMR Grouping Method on the Matchmaking Template to something reasonable for the quality calculations of your queue.
Strides currently come in two variants, Fixed and Probabilistic
Fixed
Here are some sample settings for Fixed stride generation
| Step | Overlap | Min Population |
|---|---|---|
| 1 | 6 | 40000 |
| 2 | 7 | 20000 |
| 3 | 8 | 13333 |
| 5 | 8 | 8000 |
| 8 | 10 | 5000 |
| 13 | 11 | 3076 |
| 21 | 13 | 1904 |
| 34 | 16 | 1176 |
| 55 | 20 | 727 |
| 89 | 26 | 449 |
| 144 | 40 | 277 |
| 233 | 80 | 0 |
With Fixed strides, Step largely represents how wide we want each partition of players to be,
and Overlap represents how far out of each partition we want to be able to match tickets.
The Fixed strides generator treats the population of players as if they were equally distributed, and generates strides in high/low pairs.
The high partition has a range <starting_point> - <overlap> to <starting_point> + <delta> + <overlap>.
The low partition has a range of <starting_point> - <delta> - <overlap> to <starting_point> + <overlap>.
When generation begins, the mean rank is chosen as the starting_point, and step is chosen as the delta.
This performs better at low populations where one is unlikely to have a normal distribution of players.
At high populations it will tend to pick pools that are far too large, which can overload the matchmakingfunctions and result in longer waits.
Let’s look at two extremes in the provided example, with an example rank that has a Min Mu of 0, Max Mu of 100, and a mean rank of 50
If the number of tickets in a player pool in a particular region is over 40,000, then the first stride will be used.
Partition generation will choose the mean mu of 50 as the starting point, and result in a high partition of 44 to 57, and a low partition of 43 to 56.
Then, a new starting point will be chosen by taking <previous_starting_point> + <delta> for the high partition, and <previous_starting_point> - <delta>.
So the next high partition will start at 51 and generate a range of 45 to 58. The low partition will start at 49 and yield a range of 42 to 55.
This process is continued until the strides reach the minimum and maximum allowed mu. This results in many partitions to break up the player pool.
If the number of tickets in a player pool in a particular region is less than or equal to 277, then the last stride will be used. Partition generation again starts at the mean mu of 50, and results in a high partition range of -30 to 363, and a low partition range of -263 to 130 Both of these ranges cover the entire allowable rank range of 0 to 100, and so functionally puts all players into the same partition allowing them to all be matched with each other
Example - Limiting the maximum difference in rankings between tickets in match proposals
Let’s say you have a competitive queue where you’d rather matches take a long time to put together rather than ever having somebody in a match that’s more than some specific skill distance apart.
| Step | Overlap | Min Population |
|---|---|---|
| 1 | 3 | 0 |
Here there will be a fixed number of strides that overlap with the other strides by ±3, regardless of population. This will limit tickets considered to groups where the mu is within the same 7 values.
When using a setting like this, you should carefully consider how you want to handle teams queueing together.
Allowing teams could be dangerous because there may be some tickets that break this limitation by their very existence. In that case the client shouldn’t allow such teams to queue.
The default MMR Grouping Method of average doesn’t work as well when trying to use strides to enforce a minimum spread.
If your goal is to avoid beginners in pro games, but are okay with pros using a weak teammate to get into beginner matches then it’s suggested that you use worst.
If your goal is to keep pros mostly playing together and presumed that teamed up beginners will be carried by their better friends, then it’s suggested that you use best.
Probabilistic
Here are some sample settings for Probabilistic stride generation
| Step | Overlap | Min Population |
|---|---|---|
| 233 | 1 | 40000 |
| 144 | 2 | 20000 |
| 89 | 2 | 13333 |
| 55 | 2 | 8000 |
| 34 | 3 | 5000 |
| 21 | 3 | 3076 |
| 13 | 3 | 1904 |
| 8 | 5 | 1176 |
| 5 | 5 | 727 |
| 3 | 5 | 449 |
| 2 | 8 | 277 |
| 1 | 8 | 0 |
The Probabilistic generator treats the population as a normal distribution, and creates partitions whose ranges depend on how many standard deviations we are from the mean (up to 3).
This results in the numeric relationship of Step being reversed from the Fixed generator.
With the Probabilistic generator, Step much more closely resembles the number of partitions we want to create, and as Step increases, the size of each partition decreases.
In practice, more than Step number of partitions will be created, as you'll see in examples below.
The overlaps are also smaller, and as such are more likely to keep players of different skill ratings apart from one another.
This is good at high population, but can result in large waits at lower populations
There are a few special cases with this generator based on the value of Step where the population can't be properly broken up based on 3 standard deviations,
so let's again look at a few examples using these settings.
We'll use an example rank of Min Mu of 0, Max Mu of 100, Default Sigma of 8.33, and a mean rank of 50
If the population is less than or equal to 277, the last config will be used to generate strides with Step of 1, and Overlap of 8.
The Probabilistic generator simply generates a single stride with the range 0 to 100, encompassing the entire player pool.
If the population x increases such that 277 < x ≤ 449, then strides will be generated with Step of 2 and Overlap of 8.
Three strides will be generated, based on the Default Sigma and the overlap.
- The high stride will be
[<mean> + <sigma> - <overlap>, <max_rank>], or[50.33, 100] - The middle stride will be
[<mean> - <sigma> - <overlap>, <mean> + <sigma> + <overlap>], or[33.67, 66.33] - The low stride will be
[<min_rank>, <mean> - <sigma> + <overlap>], or[0, 49.67]
If the population x again increases such that 449 < x ≤ 727, then strides will be generated with Step of 3, and Overlap of 5.
In this scenario, 5 strides will be generated. In order from the highest rank stride to lowest, it will generate
[<mean> + <sigma> * 2 - <overlap>, <max_rank>], or[61.66, 100][<mean> + <sigma> - <overlap>, <mean> + <sigma> * 2 + <overlap>, or[53.33, 71.66][<mean> - <sigma> - <overlap>, <mean> + <sigma> + <overlap>], or[36.67, 63.33][<mean> - <sigma> * 2 - <overlap>, <mean> - <sigma> + <overlap>], or[28.34, 46.67][<min_rank>, <mean> - <sigma> * 2 + <overlap>], or[0, 38.34]
Once Step becomes 4 or greater, the population can properly be partitioned. Strides are generated in the three standard deviations.
- The 1 sigma band will contain ~68% of players (34% above and below the mean) and will contain the narrowest range due to the highest population
- The 2 sigma band will contain an additional ~27% of players (13.5% above and below the end ranges of 1 sigma) and will have a slightly wider skill range
- The 3 sigma band will contain the remaining ~5% of players (2% above and below the end ranges of 2 sigma) and will have the widest skill range to account for the significantly lower population
In each band, the same calculation is used as in the Fixed generator except for the following changes:
- The
starting_pointis chosen to be the highest rank value in that band when calculating the partitions, and the lowest rank value when calculating the high partitions deltais<sigma> / <percentage_of_population>(Ex.percentage_of_populationwould be 0.34 when calculating the high and low 1 sigma bands). This weights the number of partitions such that there are many more partitions in the middle of the curve that have narrower skill ranges- The generation for the 1 sigma and 2 sigma bands stop when it reaches the outer ranges of that band. 3 sigma is still calculated all the way to the min and max allowable ranks to prevent isolating any players on the fringes
So if the population x increases such that 727 < x ≤ 1,176, strides will be calculated with Step of 5 and Overlap of 5.
This yields 8 strides.
- The widest partitions (extremely high or extremely low skill tickets) have a range of ~40.
- The narrowest partitions (tickets whose skill is closer to the middle) have a range of ~15
If we increase the population further such that 20,000 < x ≤ 40,000, strides will be calculated with Step of 144, and Overlap of 2
This yields 155 strides.
- The widest partitions have a range of ~10
- The narrowest partitions have a range of ~4.5